Software emulation of a device can be useful for a variety of purposes including prototyping and testing of devices that are in development. Software emulation can be particularly useful to developing devices for use in a communications protocol, so as to prototype and test interaction of a developing design for a device with other devices in the communications protocol.
One example of a communications protocol where software emulation of devices can play a role in device development is the Universal Plug and Play (UPnP™) device connectivity architecture, which provides a suite of communications or networking protocols for addressing, discovery, description, control, presentation and eventing. Universal Plug and Play (UpnP™) is an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and personal computers (PCs) of all form factors. (See, e.g., “Universal Plug and Play Device Architecture, Version 1.0,” Microsoft Corporation (Jun. 2000).) UPnP™ is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP™ is a distributed, open networking architecture that leverages TCP/IP and various other Internet/Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and public spaces. The UPnP™ architecture supports zero-configuration networking and automatic discovery whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices and services.
In UPnP™, devices convey their capabilities by providing a description. The UPnP™ description for a device is partitioned into two, logical parts: a device description describing the physical and logical containers, and one or more service descriptions describing the capabilities exposed by the device. Other devices (termed “control points”) that receive this description can send commands to access the capabilities of the device described in this description, and thereby control the device.
UPnP™ device and service descriptions are written by a device vendor or manufacturer. The descriptions are in XML syntax and are usually based on a standard UPnP™ Device Template and a standard UPnP™ Service Template. The standard templates are produced by a UPnP™ Forum working committee; they derive the template from the UPnP™ Template Language, which was derived from standard constructions in XML.
UPnP™ vendors can differentiate their devices by extending services, including additional UPnP™ services, or embedding additional devices. When a control point retrieves a particular device's description, these added features are exposed to the control point for control and eventing. The device and service descriptions authoritatively document the implementation of the device.
UPnP™ vendors that desire to have a particular device or service description approved as a standard, must go through the standardization process of the UPnP™ Implementers Corporation (UIC). Among other requirements, the standardization process includes obtaining four sample device implementations that conform to the description and should pass the UPnP™ Certification Test Tool.
Software emulation can be useful in this context to allow the vendors to more rapidly prototype and test device implementations for a proposed standard device or service description, before committing the implementation to hardware (e.g., by “burning” the software code for the device into the hardware).
Another useful application for software emulation relating to UPnP™ is in the development of control points. In the UPnP™ architecture, a control point is a device that operates as a controller of other devices. The control point obtains the description from a controlled device and uses the UPnP™ control protocols to invoke the capabilities exposed by the device (and described in the device's service descriptions). In developing a control point, it is useful to test that the control point interacts properly with a variety of different controlled devices, and remains robust in the presence of defective devices.
A conventional software emulation of a device is a device-specific emulation, which is purpose-built to emulate the specific device. Such conventional specific-device software emulations have drawbacks in the above-discussed context of developing implementations of descriptions to be proposed as a standard, and in testing control points.
In the context of developing implementations of a UPnP™ description to be proposed as a standard, there is a need among the device vendors to create software emulation of the devices. When a device standard is defined, it takes quite some time to get at least four implementations of the standard in place. Four implementations are necessary for the device specification to be presented for review with the UPnP™ Implementers Corporation (UIC). Further, vendors often lack expertise with the SOAP, HTTP and other protocol layers required of a UPnP™ device. From experience in certifying these devices, the UPnP™ Certification Test Tool team at Microsoft Corporation has discovered that most of the problems that vendors encounter are in parsing and creating the SOAP and HTTP packets, which are open standards. Vendors therefore have difficulty building software emulations to provide the device implementations corresponding to a UPnP™ description that are required to submit the UPnP™ description to the UIC.
In the context of testing control points, the control point is desirably tested with as large a number and variety of UPnP™ devices as possible. However, the number of devices (including software emulations of UPnP™ devices) currently available is limited. Moreover, the UPnP™ device emulations that are available typically are well formed devices (i.e., they are defect-free and correctly implement the UPnP™ protocols). Testing with such well-formed device emulations therefore may not enable the identification of failure conditions of the control points that occur in the presence of defects, such as devices with defective implementations of the UPnP™ communications protocol.